Another implementation of multisig #1079
Conversation
|
If you feel the need to move stuff around at least put it into a seperate commit. The way it is done here bloats the diff and makes it harder to review than necessary. Apart from that I think the idea is good but would require changes to ink-waterfall because the interface changes. I will give a more in depth review once the diff is cleaned up. |
xgreenx
force-pushed
the
feature/rewrite-multisig
branch
from
0ebd894 to
02e6187
Compare
|
Rebased to master=) |
HCastano
changed the title
|
@xgreenx do you want to pick this up again, or should I close it? |
|
The idea of that change is to avoid iterations throw confirmations and don't store a complex structure in the storage. |
|
If you don't mind I'd move forward with it and see how the I also wouldn't keep two Multisig examples around, so "improving" the current example is fine with me |
|
This is pretty stale so I'm gonna close this. If you ever want to pick this back up feel free to do so |
This implementation allows avoiding the storing of the order of transactions.
TransactionIdis a hash of the encoded transaction.Each transaction has a status.
PartialConfirmedstores the list of confirmations and id of the owners set when that status was created. If we updated the list of owners, that id will mismatch and it means that we need to validate that each confirmation.I think that this example is simpler in understanding.
It is only an idea. But if you think that it is not bad, I will finish it=)